Suyash Dongre [Wed, 20 Aug 2025 17:52:41 +0000 (23:22 +0530)]
[PATCH] Check if `HTTP_X_AMZ_COPY_SOURCE` header is empty
The issue was that the `HTTP_X_AMZ_COPY_SOURCE` header could be present but empty (i.e., an empty string rather than NULL). The code only checked if the pointer was not NULL, but didn't verify that the string had content. When an empty string was passed to RGWCopyObj::parse_copy_location(), it would eventually try to access name_str[0] on an empty string, causing a crash.
Fixes: https://tracker.ceph.com/issues/72669 Signed-off-by: Suyash Dongre <suyashd999@gmail.com>
Gbp-Pq: Name CVE-2024-47866.patch
[PATCH 1/4] mgr/volumes: Fix subvolume discover during upgrade
Fixes the subvolume discover to use the correct
metadata file after an upgrade from legacy subvolume
to v1. The fix makes sure, it doesn't use the
handcrafted metadata file placed in the subvolume
root of legacy subvolume.
Co-authored-by: Arthur Outhenin-Chalandre <arthur.outhenin-chalandre@cern.ch> Co-authored-by: Dan van der Ster <daniel.vanderster@cern.ch> Co-authored-by: Ramana Raja <rraja@redhat.com> Signed-off-by: Kotresh HR <khiremat@redhat.com>
Gbp-Pq: Name CVE-2022-0670.patch
[PATCH] client: prohibit unprivileged users from setting sgid/suid bits
Prior to fb1b72d, unprivileged users could add mode bits as long as
S_ISUID and S_ISGID were not included in the change.
After fb1b72d, unprivileged users were allowed to modify S_ISUID and
S_ISGID bits only when no other mode bits were changed in the same
operation. This inadvertently permitted unprivileged users to set
S_ISUID and/or S_ISGID bits when they were the sole bits being modified.
This behavior should not be allowed. Unprivileged users should be
prohibited from setting S_ISUID and/or S_ISGID bits under any
circumstances.
This change tightens the permission check to prevent unprivileged
users from setting these privileged bits in all cases.
Joshua Baergen [Wed, 17 May 2023 18:17:09 +0000 (12:17 -0600)]
CVE-2023-43040 rgw: Fix bucket validation against POST policies
It's possible that user could provide a form part as a part of a POST
object upload that uses 'bucket' as a key; in this case, it was
overriding what was being set in the validation env (which is the real
bucket being modified). The result of this is that a user could actually
upload to any bucket accessible by the specified access key by matching
the bucket in the POST policy in said POST form part.
Fix this simply by setting the bucket to the correct value after the
POST form parts are processed, ignoring the form part above if
specified.
Popen.communicate() returns a tuple (stdout, stderr), and stderr
will be of type bytes, hence the need to decode it before checking
if it's an empty string or not.
Gbp-Pq: Name CVE-2022-3650_2_ceph-crash_fix_stderr_handling.patch
If privileges cannot be dropped, log an error and exit. This commit
also catches and logs exceptions when scraping the crash path, without
which ceph-crash would just exit if it encountered an error.
Gbp-Pq: Name CVE-2022-3650_1_ceph-crash_drop_privleges_to_run_as_ceph_user_rather_than_root.patch
see also
https://www.boost.org/doc/libs/1_74_0/doc/html/boost_asio/std_executors.html#boost_asio.std_executors.polymorphic_i_o_executor
we could use `asio::any_io_executor` later on though for better
performance.
also, define CMP0093, so FindBoost reports Boost_VERSION in x.y.z
format. it is simpler to use `VERSION_GREATER_EQUAL` to compare its
version with 1.74 instead of its C macro version ("107000").
Gbp-Pq: Name cmake_define_BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT_for_Boost.Asio_users.patch
Kefu Chai [Fri, 28 Jun 2019 03:35:54 +0000 (11:35 +0800)]
[PATCH] os/bluestore/BlueFS: use uint64_t for `len`
change the type of parameter `len` of `BlueFS::_read_random()` from
`size_t` to `uint64_t`.
i think the type of `size_t` comes from
`rocksdb::RandomAccessFile::Read(uint64_t offset, size_t n,
rocksdb::Slice* result, char* scratch)`. and when we implement this
method, we continued using `n`'s type. but, we are using it with
`std::min()`, for instance, where the template parameter type deduction
fails if the lhs and rhs parameters' types are different. so probaly the
better solution is to use `uint64_t` directly to avoid the the cast and
specializing the template.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Gbp-Pq: Name bluefs-use-uint64_t-for-len.patch
unsigned and size_t are equivalent on 32 bit architectures,
so only define the size_t based overload of advance on 64
bit architectures.
https://wiki.debian.org/ArchitectureSpecificsMemo
Bug-Ubuntu: https://launchpad.net/bugs/1756854
Bug-Ubuntu: https://launchpad.net/bugs/1766998
Forwarded: no
Last-Update: 2018-04-24
Instead of -source/-target ceph should be build with --release for OpenJDK 9
or later so that the bootclasspath is also set, as per JEP-247, otherwise it
risks incurring into binary incompatibility when run with an earlier OpenJDK.
OpenJDK 11 minimum compatibility release has been updated to 7.
Last-Update: 2018-04-24
Gbp-Pq: Name update-java-source-target-flags.patch
* Non-maintainer upload by the LTS team.
* Add patch to check if HTTP_X_AMZ_COPY_SOURCE header is empty.
(Fixes: CVE-2024-47866) (Closes: #1120797)
* Add patch to fix subvolume discover during upgrade.
(Fixes: CVE-2022-0670) (Closes: #1016069)
[PATCH] client: prohibit unprivileged users from setting sgid/suid bits
Prior to fb1b72d, unprivileged users could add mode bits as long as
S_ISUID and S_ISGID were not included in the change.
After fb1b72d, unprivileged users were allowed to modify S_ISUID and
S_ISGID bits only when no other mode bits were changed in the same
operation. This inadvertently permitted unprivileged users to set
S_ISUID and/or S_ISGID bits when they were the sole bits being modified.
This behavior should not be allowed. Unprivileged users should be
prohibited from setting S_ISUID and/or S_ISGID bits under any
circumstances.
This change tightens the permission check to prevent unprivileged
users from setting these privileged bits in all cases.
Joshua Baergen [Wed, 17 May 2023 18:17:09 +0000 (12:17 -0600)]
CVE-2023-43040 rgw: Fix bucket validation against POST policies
It's possible that user could provide a form part as a part of a POST
object upload that uses 'bucket' as a key; in this case, it was
overriding what was being set in the validation env (which is the real
bucket being modified). The result of this is that a user could actually
upload to any bucket accessible by the specified access key by matching
the bucket in the POST policy in said POST form part.
Fix this simply by setting the bucket to the correct value after the
POST form parts are processed, ignoring the form part above if
specified.
Popen.communicate() returns a tuple (stdout, stderr), and stderr
will be of type bytes, hence the need to decode it before checking
if it's an empty string or not.
Gbp-Pq: Name CVE-2022-3650_2_ceph-crash_fix_stderr_handling.patch
If privileges cannot be dropped, log an error and exit. This commit
also catches and logs exceptions when scraping the crash path, without
which ceph-crash would just exit if it encountered an error.
Gbp-Pq: Name CVE-2022-3650_1_ceph-crash_drop_privleges_to_run_as_ceph_user_rather_than_root.patch
see also
https://www.boost.org/doc/libs/1_74_0/doc/html/boost_asio/std_executors.html#boost_asio.std_executors.polymorphic_i_o_executor
we could use `asio::any_io_executor` later on though for better
performance.
also, define CMP0093, so FindBoost reports Boost_VERSION in x.y.z
format. it is simpler to use `VERSION_GREATER_EQUAL` to compare its
version with 1.74 instead of its C macro version ("107000").
Gbp-Pq: Name cmake_define_BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT_for_Boost.Asio_users.patch
Kefu Chai [Fri, 28 Jun 2019 03:35:54 +0000 (11:35 +0800)]
[PATCH] os/bluestore/BlueFS: use uint64_t for `len`
change the type of parameter `len` of `BlueFS::_read_random()` from
`size_t` to `uint64_t`.
i think the type of `size_t` comes from
`rocksdb::RandomAccessFile::Read(uint64_t offset, size_t n,
rocksdb::Slice* result, char* scratch)`. and when we implement this
method, we continued using `n`'s type. but, we are using it with
`std::min()`, for instance, where the template parameter type deduction
fails if the lhs and rhs parameters' types are different. so probaly the
better solution is to use `uint64_t` directly to avoid the the cast and
specializing the template.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Gbp-Pq: Name bluefs-use-uint64_t-for-len.patch
unsigned and size_t are equivalent on 32 bit architectures,
so only define the size_t based overload of advance on 64
bit architectures.
https://wiki.debian.org/ArchitectureSpecificsMemo
Bug-Ubuntu: https://launchpad.net/bugs/1756854
Bug-Ubuntu: https://launchpad.net/bugs/1766998
Forwarded: no
Last-Update: 2018-04-24
Instead of -source/-target ceph should be build with --release for OpenJDK 9
or later so that the bootclasspath is also set, as per JEP-247, otherwise it
risks incurring into binary incompatibility when run with an earlier OpenJDK.
OpenJDK 11 minimum compatibility release has been updated to 7.
Last-Update: 2018-04-24
Gbp-Pq: Name update-java-source-target-flags.patch
* CVE-2022-3650: privilege escalation from the ceph user to root. Applied
upstream patches (Closes: #1024932).
[ Bastien Roucariès ]
* CVE-2021-3979:
A key length flaw was found. An attacker can exploit the
fact that the key length is incorrectly passed in an
encryption algorithm to create a non random key,
which is weaker and can be exploited for loss of
confidentiality and integrity on encrypted disks.
* CVE-2023-43040 rgw: Fix bucket validation against POST policies
(Closes: #1053690)
* CVE-2025-52555: an unprivileged user can escalate to root
privileges in a ceph-fuse mounted CephFS by chmod 777
a directory owned by root to gain access. The result
of this is that a user could read, write and execute
to any directory owned by root as long as they chmod
777 it. This impacts confidentiality, integrity, and availability.
(Closes: #1108410)
see also
https://www.boost.org/doc/libs/1_74_0/doc/html/boost_asio/std_executors.html#boost_asio.std_executors.polymorphic_i_o_executor
we could use `asio::any_io_executor` later on though for better
performance.
also, define CMP0093, so FindBoost reports Boost_VERSION in x.y.z
format. it is simpler to use `VERSION_GREATER_EQUAL` to compare its
version with 1.74 instead of its C macro version ("107000").
Gbp-Pq: Name cmake_define_BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT_for_Boost.Asio_users.patch
Kefu Chai [Fri, 28 Jun 2019 03:35:54 +0000 (11:35 +0800)]
[PATCH] os/bluestore/BlueFS: use uint64_t for `len`
change the type of parameter `len` of `BlueFS::_read_random()` from
`size_t` to `uint64_t`.
i think the type of `size_t` comes from
`rocksdb::RandomAccessFile::Read(uint64_t offset, size_t n,
rocksdb::Slice* result, char* scratch)`. and when we implement this
method, we continued using `n`'s type. but, we are using it with
`std::min()`, for instance, where the template parameter type deduction
fails if the lhs and rhs parameters' types are different. so probaly the
better solution is to use `uint64_t` directly to avoid the the cast and
specializing the template.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Gbp-Pq: Name bluefs-use-uint64_t-for-len.patch
unsigned and size_t are equivalent on 32 bit architectures,
so only define the size_t based overload of advance on 64
bit architectures.
https://wiki.debian.org/ArchitectureSpecificsMemo
Bug-Ubuntu: https://launchpad.net/bugs/1756854
Bug-Ubuntu: https://launchpad.net/bugs/1766998
Forwarded: no
Last-Update: 2018-04-24
Instead of -source/-target ceph should be build with --release for OpenJDK 9
or later so that the bootclasspath is also set, as per JEP-247, otherwise it
risks incurring into binary incompatibility when run with an earlier OpenJDK.
OpenJDK 11 minimum compatibility release has been updated to 7.
Last-Update: 2018-04-24
Gbp-Pq: Name update-java-source-target-flags.patch
Thomas Goirand [Thu, 27 May 2021 10:04:21 +0000 (11:04 +0100)]
ceph (14.2.21-1) unstable; urgency=high
* New upstream release, resolving these:
- CVE-2021-3509: Cross Site Scripting via token Cookie (Closes: #988888).
- CVE-2021-3524: injection of HTTP headers via a CORS ExposeHeader tag in
the Ceph Storage RadosGW (Closes: #988889).
- CVE-2021-3531: RadosGW denial of service (crash) (Closes: #988890).
see also
https://www.boost.org/doc/libs/1_74_0/doc/html/boost_asio/std_executors.html#boost_asio.std_executors.polymorphic_i_o_executor
we could use `asio::any_io_executor` later on though for better
performance.
also, define CMP0093, so FindBoost reports Boost_VERSION in x.y.z
format. it is simpler to use `VERSION_GREATER_EQUAL` to compare its
version with 1.74 instead of its C macro version ("107000").
Gbp-Pq: Name cmake_define_BOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT_for_Boost.Asio_users.patch
Kefu Chai [Fri, 28 Jun 2019 03:35:54 +0000 (11:35 +0800)]
[PATCH] os/bluestore/BlueFS: use uint64_t for `len`
change the type of parameter `len` of `BlueFS::_read_random()` from
`size_t` to `uint64_t`.
i think the type of `size_t` comes from
`rocksdb::RandomAccessFile::Read(uint64_t offset, size_t n,
rocksdb::Slice* result, char* scratch)`. and when we implement this
method, we continued using `n`'s type. but, we are using it with
`std::min()`, for instance, where the template parameter type deduction
fails if the lhs and rhs parameters' types are different. so probaly the
better solution is to use `uint64_t` directly to avoid the the cast and
specializing the template.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Gbp-Pq: Name bluefs-use-uint64_t-for-len.patch
unsigned and size_t are equivalent on 32 bit architectures,
so only define the size_t based overload of advance on 64
bit architectures.
https://wiki.debian.org/ArchitectureSpecificsMemo
projects / ceph.git / log